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Abstract. The aim of this paper is to alter the abstract definition of the 
program of the theoretical programming model which has been devel- 
oped at Eotvos Lorand University for many years in order to investigate 
methods that support designing correct programs. The motivation of this 
modification was that the dynamic properties of programs appear in the 
model. This new definition of the program gives a hand to extend the 
model with the concept of subprograms while the earlier results of the 
original programming model arc preserved. 



1 Introduction 

It is a well-known aspiration to exclusively use methods which guarantee the 
correctness of the developed program with respect to the problem [1, 5, 6] 
posed, that is, what makes it essential to find abstract mathematical def- 
inition of programming notions. At Eotvos Lorand University, a relational 
model of programming which treats the most important, fundamental notions 
of programming — problem, program, state space, variable, data type, etc. — in 
a uniform and consistent way [2, 3, 7] has been built for thirty years. 

The base of the abstract definitions of programming notions is the state 
space and their tool is the mathematical relation. The problem, for example, 
is a homogeneous binary relation over the state space that maps from the pos- 
sible initial states to the appropriate goal states. The program is defined as 
all of its executions, so it can be described by the relation that maps from any 



Computing Classification System 1998: F.3.1 
Mathematics Subject Classification 2010: 68N30 

Key words and phrases: programming model, state space, program constructions, speci- 
fication, correctness 

7 



s 



T. Gregorics 



state to the executions starting from one, where an execution is the sequence 
of the states concerned. The effect of a program is also a homogeneous binary 
relation where its domain contains the states from which the program surely 
terminates, i.e. the executions starting from these states are finite, and maps 
to states where these executions stop. The definition of the solution (when a 
program is said to solve a problem) establishes the main connection between 
the relations of the problem and the effect of the program. This theoretical 
approach makes it possible to investigate the concept and correctness of sev- 
eral kinds of program-designer methods such as program synthesis, analogous 
programming, etc. 

The main characteristic of this relational model is the special static point 
of view in which the concept of the program is a mapping and not a working, 
nonetheless it is originally dynamic. The advantage of this static point of view 
is the simple definition of the solution. Although it is not self-evident if the 
number of the components of the state space of a problem and that of a 
program are different. To prove the correctness, in this case, the program and 
the problem must be transformed into a new common state space [4]. 

In the present model however, the state space is persistent, i.e. all variables 
of the program are global and static (the scope and life time of the variables 
involve the whole program), the so-called local variables cannot be created 
and destroyed during an execution. In absence of local variables, the concept 
of real subprograms cannot be introduced into our programming model. (Only 
macros can be defined.) Namely, the power of a subprogram is what permits 
creating new local auxiliary variables as well as parameter variables, and it is 
not supported by the present concept of the program. It is not a serious prob- 
lem if simply the correctness is wanted to be proved but it is a great difficulty 
if our aim is to design a program. Unfortunately, the programming method, 
which is based on our programming model to synthetize correct programs, 
cannot produce subprograms with parameter variables, so their creation re- 
mains in the sphere of the implementation instead of the designing. It is an 
additional disadvantage that, without the concept of subprograms, recursive 
calling cannot be used in our programming model. 

The aim of this paper is to remedy this shortcoming of the definition of the 
program, and to preserve the earlier results of the programming model. 
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2 State space 

All definitions of the programming model are based on the state space. The 
concept of the state space has already been interpreted in several ways. For 
many people, the state space is a model of a von Neumann type computer; 
others, e.g. Dijkstra [1], associate this notion with the problem to be solved, 
where a state is a compound of the values of the main data types. So, the 
program is "outside" of the state space operating on it. In our programming 
model, this second meaning is used. In [2], the notion of the state space is 
a Cartesian product of the value set of data types. The only mistake of this 
obvious definition is that it imposes an order on the components. In [3] , where 
the state space is a direct product, this mistake is repaired. 

Here it is the definition of the direct product and the notions related to it. 

Let I be a finite set named as index set. Let A^'s (i e I) be arbitrary sets. 

The set X A^ ::= {x : I — > [J ieI Ai|Vi e I : x(i) e A^} is the direct product of 
iel 

the sets Aj (i e I). 

The Ai's are the components of the direct product X A^. The number of 

iel 

the components is finite. The direct product is the empty set if the set I is 
empty. 

Let A = X At and B = X B, be direct products where I and J are finite 
iel jej 

sets, Ai's (i £ I) and Bj's (j e J) are arbitrary sets. The A and B are equivalent 
if there exists a bijection v : I — > J so that Vt e I : A^ = B v (^ . In other words, 
B is the renamed A. 

If J Q I and Vj e J : Bj = Aj then B is the subspace of A, i.e. B ^ A. 

The function prs : A — ► B is a projection if B < A and Vae A: PTb(q) = a|j. 
Not only one state but a set or sequence of states can also be projected if it is 
done one by one. If J = {j} then the function prg is named as j variable and j 
is the variable name. 

3 The new concept of the program 

The most important notion of the programming model is the program. In our 
explanation, the program is not a collection of some statements that can be 
executed on a computer. The statements could only describe a program but 
the program is the complex of its executions. An execution is a sequence of 
states. A program, by definition, can always begin, i.e. at least one execution 
has to start from each state. If several executions start from the same start 
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state, it means that the program is non-deterministic: nobody knows which 
execution will happen. 

In the original programming model, every state of the progam belongs to 
the same state space. Now we are going to permit that the state space can 
be permanently changed; the inner states of the executions may have got new 
components. 

The other novelty of our new definition is the idea of the base state space 
of the program. The first state (start state) of all executions and the last, if 
the execution is finite, are in this base state space. 

Before giving the formal definition of the program, some notions must be 
introduced. Let H** denote the set of all finite and infinite sequences of the 
elements of set H. H 00 includes the infinite sequences; H* contains the finite 
ones. So, H** = H* u H 00 and H* n H 00 = 0. The length of the sequence 
a e H** is |a|, the value of which is oo if the sequence is infinite. 

Definition 1 Let A be the so-called base state space and A be the set of all 
states which belong to the state spaces B whose subspace is A, i.e. A = (J A<B B. 
The relation S Q A X A** is a program over A, if 

1. Ds = A (domain ofS), 

2. Vex e n A* : cti a i e A (the last state of the finite executions of the 
range of S ), 

3. Vae A and Va e S(a) : |a| ^ 1 and ai = a. 

The variables of the base state space are the base variables; the other 
variables are the auxiliary variables of the program. 

The concept of the program allows to create and destroy new components 
(variables) during an execution, so the state space changes dynamically. All 
new components have to be destroyed at the termination, at the very latest, 
but the base variables should never be removed. The current state always 
contains the components of the base state space. 

The following three definitions will outline that the base state space of any 
program is denoted arbitrarily. The base variables of a program can be ex- 
tended, restricted or renamed without changing the essence of the program. 

The base variables of any program can be renamed easily without the exe- 
cution of the program is changed. However, if the new name of a base variable 
would be identical to an auxiliary variable's name then this auxiliary variable 
is given a new, unique name. 
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Definition 2 Let the statespace A and B be equivalent, i.e. if A = X Aj, and 

iel 

B = X Bj then there exists a bijection y : I — » J so i/ia£ Vi e I : A^ = B v ^ . Let 
jej 

S be a program over the state space A. Let the name of the auxiliary variables 
ofS beK (KnI = 0) and a bijection U- : K — > L so that LnJ = 0. The program 
over B is called the variable renaming of S onto B if its executions are 
identical to the executions of S, but in their all states, the variable name iel 
is replaced by v(i) and the variable name k e K is replaced by |x(k). 

Not only can the name of the variables be changed but also the number of 
the components of the base state space: this state space can be extended with 
new variables, or some base variables can be degraded to auxiliary varibles. 

The next definition shows that the base state space can be extended with a 
new component. The states of the executions can be extended with this new 
component if it is not the auxiliary variable of the original program. Otherwise 
if this component was an auxiliary variable, then it becomes a base variable; 
it should not be created and destroyed it, its life expands over the whole 
execution. 

Definition 3 Let S be a program over the state space A = X A^ and the vari- 

iel 

able name k where k ^ I. (This k may denote one of the auxiliary variables of 

S or a totally new variable.) Let C be the statespace X A^. The extension 

ielu{k} 

of S onto C is the program ( denoted by S ') whose base state space is C and 
for all c £ C : 

S'(c) = {y e C**| 3a e S(pr A (c)) : |cc| = |y| a Vi e [2..| T |] : 

if k $ D a . then = and y i (k) = Yi-1 (k) 
if k e T> Ui then yt = &{}. 

It is easy to generalize this definition in case the state space A is a subspace 
of the state space C. 

The following definition shows how a base variable can be degraded to an 
auxiliary variable: the first step creates it and the last step destroys it. 

Definition 4 Let S be a program over the state space A = X A; and let C be 

iel 

the subspace of A. The restriction of S onto C is the program (denoted by 
S ) whose base state space is C and for all c e C: 

S(c) = { < c, a,prc(ai a i) >e C*|a e S(a) n A* where c = prc(a) } 
u { < c, a >e C^ja e S(a) n A™ where c = prc(a) }. 
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The base state space of a program can be renamed, extended or restricted 
several times, thus the base state space can be totally transformed. But these 
transformations can change only the base state space and not the program. 
The essence of the executions of the program remains the same. The renamed, 
extended and restricted program hardly differs from its original version. 

Definition 5 Two programs are identical if they can transform into the same 
program, using extensions, restrictions and renaming. 

4 Conclusions 

We have introduced a new concept of the program. Now let us observe what 
kinds of effects this modification has on the original programming model. 

4.1 Concept of dynamic program 

The new concept of the program smuggles the dynamic property of the pro- 
gram back to the static programming model [2, 3] developed at Eotvos Lorand 
University. Certainly, the fact that a program can create and destroy auxiliary 
variables is not a brilliant discovery. The difficulty of our investigation was to 
find out how this dynamic property can be embedded into the programming 
model described in the static point of view. 

The most important element of our concept is the base state space. It can 
be seen as the interface of the program. It determines the components through 
which the program can communicate, and can make contact with its environ- 
ment. Only the base variables can get value from outside before the program 
starts, and their value can be asked after the termination. 

The program becomes very flexible because its base state space can be 
changed easily. This property is reflected in the fact that the same program 
can possess different interfaces depending on the problem to be solved. The 
aim of a program can be changed by altering its base state space whereas its 
operation cannot be changed. 

4.2 Concept of solution 

Despite the above modification, the definition of the solution can be preserved 
[2, 3, 7]. The only thing that must be done is to redefine the concept of the 
effect of the program because the definition of the solution relies on it. 

Now we will repeat all definitions that are important to describe the concept 
of solution. 
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Let the problem generally be a relation F c A x A where A is a state space. 
Let S be a program over A. The relation p(S) S A X A is the effect of S if 

1. D p(s) = {a e A | S(a) Q A*} 

2. Va e D p(s) : p(S)(a) = {b e A | 3a e S(a) : a N = b}. 
The program S is said to solve the problem F if 

1- % e D p(s) 

2. Va 6 Dp : p(S)(a) c F(a) 

The definition of the solution supposes that the state space of the problem 
is identical to the base state space of the program. As the base state space can 
be chosen arbitrarily, the program can be extended, restricted or renamed in 
order that its base state space is identical to the state space of the problem. 
Since programs of this kind are identical, if one of them can solve the problem, 
so can the others. 

Moreover, if the effects of the programs Si and Sz are identical over all 
common base state spaces (p(Si) = p(S2)) and if one of them can solve a 
problem, so can the others. In this case these programs are called equivalent. 
This relation is reflexive, symmetrical and transitive, thus it is an equivalence 
relation. Consequently, if one program belonging to an equivalence class can 
solve a problem, then every program derived from this class can also solve it. 

In the original programming model, the definition of the solution must be 
generalized [4] when the state spaces of the problem and the program are 
different. Now, our new concept is used to avoid this. It is enough to fit the 
base state space of the program to the state space of the problem and transform 
the program onto this common state space. 

4.3 Earlier results 

The original programming model contains many important results that can 
be used in the verification of programs. It is apparent that these results are 
not based directly on the concept of the program; except for the effect of the 
program. The definition of the effect of the program has not been changed 
because the new definition of the program fixes that the start state and the 
end state of the finite execution are in the same state space (that is, the 
base state space). Accordingly, all earlier results, namely Dijkstra's weakest 
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precondition [1], the theorem of the specification or the derivation rules [1, 3] 
of the program constructions [3] are used in unalterable forms. 

Certainly, in the definitions of program constructions, the components (pro- 
grams and conditions) which are the parts of the construction have to be on the 
same base state space. Accordingly, before making one of the constructions, 
this common base state space has to be agreed on. 

4.4 Subprograms 

The concept of real subprograms, which have got parameter variables, could 
not be introduced into the original programming model because the program 
has got an unvarying state space, thus local variables cannot be created during 
the execution, so parameter variables, which are local variables, cannot be 
used. Now, the situation is changed. In our new programming model, the 
concept of the subprograms may be defined. 

First and foremost the subprogram is a program. It can be executed inde- 
pendently; it has got own base state space. Its only speciality is that it can be 
built into another program. (This is the host program.) 

Each program, including subprograms, is equivalent to an assignment. This 
assignment is appropriate to identify the subprogram that is equivalent to 
it. Accordingly, in an arbitrary program description language, a subprogram 
can be denoted with this assignment. The variables of this assignment, which 
are the formal parameters, form the base state space of the subprogram. The 
variables at the left-hand side of the assignment are the output parameter 
variables; the ones at the right-hand side are the input parameter variables. 
(For simplicity's sake, we shall restrict our consideration to assignments where 
a parameter variable does not occur more than once.) 

This assignment can be also used as a calling statement in the description of 
the host program. Certainly, in the calling statement, the parameter variables 
can be substituted by actual parameters (arguments), which are the expres- 
sions (often, they are only variables) of the host program. An output variable 
cannot be changed by an expression more general than a variable. The num- 
ber and the type of the formal and current parameters must be the same. 
At this calling statement, the execution of the host program is interrupted, 
the control switches over the subprogram, the values of current parameters 
are given to the formal parameter variables, and the subprogram is executed. 
After the termination of the subprogram, the values of the output parameter 
variables are recopied to the appropriate current parameter variables. (Here, 
two kinds of parameter passing have been defined: passing by value and passing 
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by value-result but other passing methods may be introduced.) 

The base state space of the subprogram is the interface between the subpro- 
gram and the host program. At the beginning of the subprogram, the variables 
of this base state space will get their initial values from the current state of the 
host program. At the end of it these variables give their values to the variables 
of the host program. The parameter variables and other local variables of the 
subprogram are created when the subprogram is called and destroyed at the 
termination of the subprogram. 

In addition, the usage of subprograms permits recursive callings because 
a subprogram can call itself. After each calling, the parameter and the local 
variables of the subprogram are created again and again without the error 
message "out of memory" because the memory of the abstract program is 
infinite. 

During planning, it is convenient that all the current variables of the host 
program are treated as global with respect to the subprogram that is called 
by the host program. The applied programming style and the facilities of the 
selected programming language determine if these global variables can be used 
directly in the subprogram or not. Obviously, their use has to be forbidden if 
we want to guarantee the independency of the subprogram. 

We can make difference between the calling statement and the calling ex- 
pression. In the latter case, only the right-hand side of the subprogram's head 
appears inside an expression of the host program, which contains actual pa- 
rameters instead of formal parameter variables. After the termination, the 
result value of the left-hand side of the head is given back to the place of the 
calling expression in the host program. 

Certainly, the abstract program description language which is used for plan- 
ning has to be extended with the notation of the subprogram and of its calling 
including the connection between the actual parameters and the parameter 
variables. 

To sum up the introduction of the concept of the subprograms makes it 
possible to design subprograms during planning and not only during imple- 
mentation. 
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